In earlier days, engineers typically wrote control code for test and measurement systems in assembly language, a low-level language. Today, however, to improve development time and to enable the creation of programs having greater functionality and complexity to be developed in shorter time, engineers typically employ high-level languages, for example C, C++, etc. The high-level language is converted into machine code for operation on the particular processor, by a compiler/assembly/linker system, which generates assembly language and/or machine code based on the high-level source code.
Unfortunately, when debugging the program, the engineer must work with the low-level machine code. The low-level machine code is a series of binary numbers, or hexadecimal codes (base 16) and is not easy to understand. Typically, the machine code is reconverted to assembly language by a disassembler program to aid the engineer to understand the code that he is viewing.
However, the engineer did not write the software in assembly language. Moreover, the engineer may be unfamiliar with the methods employed by the compiler to generate assembly language code corresponding to various source code statements. Thus, it becomes complicated for the engineer to understand the exact operation of the system during a debugging operation.
Substantially all computer programs must be debugged because of their complexity, and because human programmers make mistakes. Computer code that performed well in simulation may fail to perform adequately under “real world” conditions for a variety of reasons, such as the relative unpredictability of the timing and form of real world input signals. Traditional software debuggers perform disassembly of code residing on the system under test (also known as the target system) and aid in the troubleshooting of code that is not performing as expected. Disassembly of computer code is the process of converting machine code back into assembly language for ease of understanding by a programmer or engineer troubleshooting a problem. Software debugger based disassemblers typically have access to the target system memory by way of an emulator probe or serial connection, such as through a JTAG port. Using this access, they are able to perform disassembly based on the memory image in the target system, translating the code found there into higher-level assembly language.
Disassembler software can also be run on a logic analyzer, such as a TLA 700 Series Logic Analyzer, manufactured by Tektronix, Inc. of Beaverton, Oreg. Such a disassembler running on a logic analyzer is described in U.S. Pat. No. 6,016,556, entitled SYSTEM FOR IDENTIFYING AN ACQUISITION SAMPLE CORRESPONDING TO A SOURCE CODE STATEMENT, (Heath), issued 18 Jan. 2000, assigned to the same assignee as the subject invention, and hereby incorporated by reference. Disassembler software running on a logic analyzer translates low-level machine code, of the target system under test, into easy-to-understand higher-level language as a troubleshooting aid to the user of the logic analyzer. Unfortunately, a disassembler running in a logic analyzer does not have access to the memory of the system under test. It therefore cannot operate on an image of that memory to translate the code. Moreover, a logic analyzer cannot interrogate the system under test to determine the contents of a particular memory location. A logic analyzer can only monitor bus traffic on the target system, and attempt to interpret the binary data that it acquires from the bus.
In a logic analyzer, the process of disassembly involves converting acquired bus transaction records into a listing of assembly language instructions that, when executed, would have generated that bus activity. This conversion process is sometimes ambiguous as a result of a variety of circumstances such as insufficient transaction history, variable length instructions, and lack of an instruction fetch indicator. When any of these conditions occur, the conversion process will most likely suffer. That is, the conversion process sometimes makes an incorrect assumption about where a new assembly language instruction, known as an op-code, actually begins. The disassembler often mistakes data or address information for an op-code, and consequently incorrectly disassembles the given set of bus transactions, because the disassembler was pointed to an incorrect starting address.
To compensate for this ambiguity, disassemblers currently provide a mechanism known as “mark op-code”, which enables a user to manually indicate the correct starting address for an assembly language instruction. There are two significant problems with this solution. First, users must recognize when the displayed disassembly trace is incorrect and then figure out where it went wrong in order to know where to place the op-code mark. This can be confusing and error prone because the user is usually looking at unfamiliar code. Second, users must manually mark numerous such locations as they examine different parts of an acquisition trace. This manual marking procedure can be cumbersome and time consuming, especially because the user must frequently “jump” to new locations in the acquisition buffer that have not been previously disassembled. What is needed is a disassembler for a logic analyzer that more efficiently, more precisely, and automatically resolves most of these starting address ambiguities.